Nautilus 1992 July/Nautilus-3-8/Nautilus-3-8.bin/Tools & Utilities/Techy Stuff/Doco ƒ/CSMP ƒ/CSMP-V1-093.TXT

Text File | 1992-06-30 | 34.5 KB | 933 lines

C.S.M.P. Digest             Mon, 25 May 92       Volume 1 : Issue 93

Today's Topics:

    Want to trap writeln/readln in MPW pascal
    "Faceless" applications
    MF scrap && DialogSelect crash
    FileFilter Procedure.  Think C 5.0 StandardGetDialog.
    smooth scrolling
    Are you a developer? Ive got a question.


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The digest is a collection of articles from the internet newsgroup comp.sys.
mac.programmer.  It is designed for people who read c.s.m.p. semi-regularly
and want an archive of the discussions.  If you don't know what a newsgroup
is, you probably don't have access to it.  Ask your systems administrator(s)
for details.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (James Terman)
Subject: Want to trap writeln/readln in MPW pascal
Organization: Columbia University
Date: Sun, 19 Apr 1992 07:58:04 GMT

I would like to use writeln/readln commands to write to a window/read from
the keyboard.  Is there a procedure name that the compilier use that I could
override from Paslib to put in my own routine?

| James L. Terman "Future Dead White Male" | Science may set limits to know-  |
| [e-mail]               | ledge, but should not set limits |
| [e-mail]  | to imagination.              |
|                       |            - Bertrand Russell |

+++++++++++++++++++++++++++

From: [e-mail] (Dave Seaman)
Date: 19 Apr 92 16:43:59 GMT
Organization: Purdue University Computing Center

In article <[e-mail]> [e-mail] (James Terman) writes:
>I would like to use writeln/readln commands to write to a window/read from
>the keyboard.  Is there a procedure name that the compilier use that I could
>override from Paslib to put in my own routine?

If you write an MPW tool program (not an application), then writeln and readln
do what you want by default (i.e. unless you have specified redirection on the
command line by using the Unix-style < and > operators).

Why do you want to override the existing routines?

- --
Dave Seaman
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 23 Apr 92 21:58:04 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Jon Pugh) writes:
>
> In article <[e-mail]>,
[e-mail] (James Terman) writes:
> >
> > I would like to use writeln/readln commands to write to a window/read from
> > the keyboard.  Is there a procedure name that the compilier use that I could
> > override from Paslib to put in my own routine?
>
> There is a new library that I have heard of called SWIO or somesuch that
> does Standard Window IO.  Look for it in the recent MPW releases.  I don't
> have the info here, but it should be on ETO and maybe the Dev CD.

It's called SIOW, and it's part of MPW 3.2

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

---------------------------

From: [e-mail] (Steve Fuller)
Subject: "Faceless" applications
Organization: Iowa State University, Ames IA
Date: Fri, 17 Apr 1992 20:51:29 GMT

After using Trashman and not having it show up in the task list,
I'm wondering if it is possible to hack at a program with ResEdit
and get it to not show up in the task list as well, or is this
a feature that must be built into an appliction at compile
time???


- --
- ---------------------=---------------------------------------------------
Steve Fuller         = Critics are like eunuchs in a harem. They know
Net.nerd             = how it's done, they've seen it done every day,
[e-mail] = but they're unable to do it themselves. B. Behan

+++++++++++++++++++++++++++

From: [e-mail] (Dan Walkowski)
Organization: University of Illinois at Urbana
Date: Sat, 18 Apr 1992 03:30:38 GMT

[e-mail] (Steve Fuller) writes:

>After using Trashman and not having it show up in the task list,
>I'm wondering if it is possible to hack at a program with ResEdit
>and get it to not show up in the task list as well, or is this
>a feature that must be built into an appliction at compile
>time???


>--
Why didn't you just _ask_ me? :-)
The short answer to your question is 'no'.
The longer answer is 'No, because the program isn't allowed to call InitWindows
(or InitMenus, I think) and must be of type 'appe', instead of APPL.'
This means, of course, that no program that has any windows can do this.
If you want more details, send me email.


- --
Dan Walkowski
Univ. of Illinois
[e-mail]
- ---------------------------------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Jack Littleton)
Date: 20 Apr 92 17:02:18 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Steve Fuller) writes:
>I'm wondering if it is possible to hack at a program with ResEdit
>and get it to not show up in the task list as well, or is this
>a feature that must be built into an appliction at compile
>time???

You can partially make a program faceless by setting the "canBackground" and
"onlyBackground" attributes are set in the SIZE resource.  However, since the
by-laws of Faceless Applications state that they can olny receive high level
and null events, just setting those attributes won't cut it.  Not only that,
but if the program you modify draws windows, menus, etc., it totally blows
the concept of "Facelessness".

I'm gonna get 'faced.

Jack Littleton
Development Tools Engineering
Apple Computer, Inc.

* The opinion stated above are not necessarily those of Apple Computer, Inc. *

- --
Jack Littleton                Internet: [e-mail]
MPW Compiler/Linker group     AppleLink: JACINTOSH
Apple Computer, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Ross Brown)
Date: 21 Apr 92 12:14:17 GMT
Organization: Bell-Northern Research

In article <[e-mail]> [e-mail] (Jack Littleton) writes:
>You can partially make a program faceless by setting the "canBackground" and
>"onlyBackground" attributes are set in the SIZE resource.  However, since the
>by-laws of Faceless Applications state that they can olny receive high level
>and null events, just setting those attributes won't cut it.  Not only that,
>but if the program you modify draws windows, menus, etc., it totally blows
>the concept of "Facelessness".

Please, where are these "by-laws" recorded?  There's not much in IM VI about
background-only applications.

Ross Brown
Bell-Northern Research Ltd.
Ottawa, Ontario, Canada
[e-mail]
Opinions expressed do not necessarily represent those of BNR.

+++++++++++++++++++++++++++

From: [e-mail] (Mel Walker)
Organization: Novell, Inc. - Walnut Creek
Date: Tue, 21 Apr 1992 15:58:00 GMT

In article <[e-mail]> [e-mail] (Ross Brown) writes:
>In article <[e-mail]> [e-mail] (Jack Littleton) writes:
>>You can partially make a program faceless by setting the "canBackground" and
>>"onlyBackground" attributes are set in the SIZE resource.  However, since the
>>by-laws of Faceless Applications state that they can olny receive high level
>>and null events, just setting those attributes won't cut it.  Not only that,
>>but if the program you modify draws windows, menus, etc., it totally blows
>>the concept of "Facelessness".
>
>Please, where are these "by-laws" recorded?  There's not much in IM VI about
>background-only applications.

They're not so much "laws" as "consequences". They recieve null events since
they're in the background, and they can receive high-level events if the
appropriate bit is set. They can't receive activate/update events (no windows),
mousedown/up events (no windows, in the background), os events (since they are
_always_ in the background), keydown/autokey (since they're in the background),
etc. If you can get a hold of develop volume 9, it has an article about FBAs.
It claims that you can only call InitGraf from an FBA, and no other visual
manager (like InitWindows, InitFonts, etc). Otherwise, it's not a faceless
background app.
- --Mel Walker
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 23 Apr 92 17:41:13 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Ross Brown)
writes:
> In article <[e-mail]> [e-mail] (Jack Littleton) writes:
> >You can partially make a program faceless by setting the "canBackground" and
> >"onlyBackground" attributes are set in the SIZE resource.  However, since the
> >by-laws of Faceless Applications state that they can olny receive high level
> >and null events, just setting those attributes won't cut it.  Not only that,
> >but if the program you modify draws windows, menus, etc., it totally blows
> >the concept of "Facelessness".

> Please, where are these "by-laws" recorded?  There's not much in IM VI about
> background-only applications.

Be patient, C.K. in our group wrote a d e v e l o p article about
background only apps, and it should be published soon. Meanwhile check
his snippets on the Developer CD (or ftp.apple.com).

Cheers,
Kent Sandvik
Dynamic Languages will take over the world...

---------------------------

From: [e-mail] (Pete Gontier)
Subject: MF scrap && DialogSelect crash
Date: 16 Apr 92 05:15:04 GMT

After two years of INIT hacking, I've forgotten a lot of application
boilerplate stuff. Or maybe I'm just getting old.

1. What's the correct incantation to get MultiFinder to recognize it should
propogate your changes to the scrap? After reading a bit, I divined it must
be that you should call SystemEdit to tell MF you're handling one of the
standard menu items. But what to pass? IM says to pass the item in the Edit
menu - 1. But that doesn't work. What does work is item + accMenu. Ideas?

2. What are the most common causes of crashes when calling DialogSelect?

3. Where's some code that scans the event queue for a command-period?

+++++++++++++++++++++++++++

From: [e-mail] (Phil Shapiro)
Date: 21 Apr 92 16:02:01 GMT
Organization: Symantec Corp.

In article <[e-mail]> [e-mail] (Pete Gontier) writes:


   1. What's the correct incantation to get MultiFinder to recognize
   it should propogate your changes to the scrap? After reading a bit,
   I divined it must be that you should call SystemEdit to tell MF
   you're handling one of the standard menu items. But what to pass?

SystemEdit(copyCmd);  // because PutScrap works like the Edit menu's Copy

   3. Where's some code that scans the event queue for a
   command-period?

The easiest way to do this (that I've seen) is to hook PostEvent() to
set a global flag if it sees a command-period. This may sound ugly,
but it's cleaner than other techniques I've seen. It removes any
overhead from calling EventAvail() or GetNextEvent(), and it doesn't
have the problems of calling GetOSEvent() or (shudder!) looking at the
event queue directly.

    -phil
- --
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Tue, 21 Apr 1992 17:20:14 GMT

[e-mail] (Phil Shapiro) writes:
>[e-mail] (Pete Gontier) writes:
>>
>>3. Where's some code that scans the event queue for a
>>   command-period?
>
>The easiest way to do this (that I've seen) is to hook PostEvent() to
>set a global flag if it sees a command-period. This may sound ugly,

Well, no argument here.

>but it's cleaner than other techniques I've seen. It removes any
>overhead from calling EventAvail() or GetNextEvent(), and it doesn't
>have the problems of calling GetOSEvent() or (shudder!) looking at the
>event queue directly.

Remember, this comes from a guy whose company distributes code that does
exactly that.  :-)  Check out AbortInQueue(), in TBUtilities.c
(TCL 1.1)--it walks the queue.  I must be missing something--what's so
bad about doing this?
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 I can't contain the furnace where there used to be a guy...

+++++++++++++++++++++++++++

From: [e-mail] (Phil Shapiro)
Date: 21 Apr 92 22:22:46 GMT
Organization: Symantec Corp.

In article <[e-mail]> [e-mail] (Jamie R. McCarthy) writes:

   >but it's cleaner than other techniques I've seen. It removes any
   >overhead from calling EventAvail() or GetNextEvent(), and it doesn't
   >have the problems of calling GetOSEvent() or (shudder!) looking at the
   >event queue directly.

   Remember, this comes from a guy whose company distributes code that does
   exactly that.  :-)  Check out AbortInQueue(), in TBUtilities.c
   (TCL 1.1)--it walks the queue.  I must be missing something--what's so
   bad about doing this?

This is bad because it will give you false alarms about
command-periods when your app is in the background. The low memory
queue corresponds to the OS Event queue, which contains all events
before the Process Manager distributes them to applications.

This is how THINK C does it as well -- I had to patch GetOSEvent to
prevent it from stealing keydowns to get THINK Back to work properly.

Regarding the TCL, I'll see about getting this fixed. As long as you
don't try to call AbortInQueue() when you're in the background, you
should be OK.

Does anyone know if code like this is A/UX compatible?

    -phil
- --
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 22 Apr 92 09:31:48 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.kzoo.edu> [e-mail] (Jamie R. McCarthy) writes:

   >The easiest way to do this (that I've seen) is to hook PostEvent() to
   >set a global flag if it sees a command-period. This may sound ugly,

   Well, no argument here.

   >but it's cleaner than other techniques I've seen. It removes any
   >overhead from calling EventAvail() or GetNextEvent(), and it doesn't
   >have the problems of calling GetOSEvent() or (shudder!) looking at the
   >event queue directly.

   Remember, this comes from a guy whose company distributes code that does
   exactly that.  :-)  Check out AbortInQueue(), in TBUtilities.c
   (TCL 1.1)--it walks the queue.  I must be missing something--what's so
   bad about doing this?

Well, cmd-period is tricky because of international keyboards. You
would almost have to call keytrans yourself...

Apart from that, the event queue is in no-no memory under A/UX and is
NOT available to applications except for EventAvail type calls. And
we've all heard that System 8 will look much like A/UX in the memory
protection regard...

- --
"You should meet yourself someday. I'm sure you would hate it."
- - Me: [e-mail]; Jon W{tte (The Diplomat - NOT!)

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 24 Apr 92 01:20:21 GMT
Organization: MacDTS Mongols

In article <[e-mail]>,
[e-mail] (Phil Shapiro) writes:
>
> In article <[e-mail]> [e-mail]
(Jamie R. McCarthy) writes:
>
>    >but it's cleaner than other techniques I've seen. It removes any
>    >overhead from calling EventAvail() or GetNextEvent(), and it doesn't
>    >have the problems of calling GetOSEvent() or (shudder!) looking at the
>    >event queue directly.
>
>    Remember, this comes from a guy whose company distributes code that does
>    exactly that.  :-)  Check out AbortInQueue(), in TBUtilities.c
>    (TCL 1.1)--it walks the queue.  I must be missing something--what's so
>    bad about doing this?
>
> This is bad because it will give you false alarms about
> command-periods when your app is in the background. The low memory
> queue corresponds to the OS Event queue, which contains all events
> before the Process Manager distributes them to applications.
>
> This is how THINK C does it as well -- I had to patch GetOSEvent to
> prevent it from stealing keydowns to get THINK Back to work properly.
>
> Regarding the TCL, I'll see about getting this fixed. As long as you
> don't try to call AbortInQueue() when you're in the background, you
> should be OK.
>
> Does anyone know if code like this is A/UX compatible?

Peeking at the event queue directly won't work under A/UX, it's a nice
little boy that keeps the event queue inside the kernel address space.

Tech Note 263 talks about how to intercept command-dot. Here's also
some code (Dave Radcliffe wrote it?) that takes into account the A/UX
case. Sorry it looks very much C++:ish because I recycled the code in
a C++ project:


//    Pure MacOS routines
/*
 *    Ascii2KeyCode translates an ASCII character into a virtual keycode.
 *    This is used to locate the '.' key no matter what language or keyboard
 *    is in use.
 *
 *    This should be called anytime the keyboard script changes (which can
 *    be determined with GetEnvirons (smKeyScript)).
 *
 *    It returns the virtual keycode, or -1 in the event it can't find they key.
 */

pascal char TIntDialogBehavior::Ascii2KeyCode (char asciiChar)
{
    char    keyCode;
    Boolean    notDone;
    short    KCHRId;
    Ptr        pKCHR;
    Handle    hKCHR;
    long    state;
    long    ktResult;

    hKCHR = nil;
    pKCHR = (Ptr) GetEnvirons (smKCHRCache);    /* Try to get pointer directly */

    if (!pKCHR) {                                /* For pre-System 7.0 compatibility */
        KCHRId = (short) GetScript (short(GetEnvirons (smKeyScript)), smScriptKeys);
        hKCHR = GetResource ('KCHR', KCHRId);    /* Get the KCHR resource */
        pKCHR = *hKCHR;                            /* Get the pointer */
    }

    notDone = true;
    if (pKCHR) {
        keyCode = 0;
        state = 0;

        while ((keyCode <= 0x7F) && notDone) {    /* Loop through all possible keycodes
*/
            ktResult = KeyTrans ((pKCHR), keyCode, state);    /* Get the ASCII value */
            if (((ktResult & ktAscii1Mask) == asciiChar) ||
                ((ktResult & ktAscii2Mask) == asciiChar))     /* Check result for desired char
*/
                    notDone = false;
            else
                keyCode++;                        /* Keep looking */
        }
    }

    if (hKCHR)
        ReleaseResource (hKCHR);                /* Clean up */

    if (notDone)
        return (-1);
    else
        return (keyCode);
} /* Ascii2KeyCode */


/*
 *    CheckAUXEventQueue looks in the A/UX event queue for a key event with
 *    the specified keyCode and modifiers.
 *
 *    A/UX does not support the event queue in the Macintosh sense.  Instead,
 *    it maintains a separate data structure in the Unix kernel which is not
 *    directly accessible from a Macintosh application.  To get around this
 *    problem, a special trap called AUXDispatch is provided which allows us
 *    to get the information we need.
 *
 *    CheckAUXEventQueue returns true if it finds the appropriate event.
 *
 *    CheckAUXEventQueue should only be called if A/UX is present.
 */
#define AUX_FIND_EVENT       8
pascal long    AUXDispatch(short selector, char *p)
    = {0xABF9};

pascal Boolean TIntDialogBehavior::CheckAUXEventQueue (char keyCode, short
modifiers)
{
    struct {
        EventRecord        mask;
        EventRecord        value;
    } eventFilter;

    eventFilter.mask.what = everyEvent;
    eventFilter.value.what = keyDown;            /* Look for a keydown event */
    eventFilter.mask.message = keyCodeMask;
    eventFilter.value.message = keyCode << 8;    /* Set keyCode */
    eventFilter.mask.modifiers = modifiers;
    eventFilter.value.modifiers = modifiers;    /* Set modifiers */
    eventFilter.mask.when = 0;
    eventFilter.mask.where.v = 0;                /* Zero out other stuff */
    eventFilter.mask.where.h = 0;
    return ((AUXDispatch (AUX_FIND_EVENT, (char *) &eventFilter) > 0) &&
        (eventFilter.value.what != nullEvent));    /* Have A/UX look for us */
}    /* CheckAUXEventQueue */

/*
 *    UserDidAbort returns true if the user has pressed Command-Period.
 *
 *    It does this by walking the event queue.  Walking the event queue is not
 *    recommended, but since we want a Command-Period event to take priority over
 *    any other events in the queue, looking ahead in the queue is the only way.
 *
 *    Note that for A/UX, this technique does not work as A/UX does not support
 *    the Macintosh event queue structure.  In that case, we call
CheckAUXEventQueue
 *    to find the result.
 */

pascal Boolean TIntDialogBehavior::UserDidAbort ()
{
    Boolean        foundEvent;
    char        periodKeyCode;
    EvQElPtr    eventQPtr;
    QHdrPtr        eventQHdr;

    /*
     *    It would be best to make periodKeyCode a global and only change it when
     *    the keyboard script changes.  To know when that happens, you could keep
     *    another global, called for example, currentKeyScript, call Ascii2KeyCode
     *    once to initialize periodKeyCode and only call it again if the script
     *    has changed:
     *
     *    if (currentKeyScript != GetEnvirons (smKeyScript))...    // Check to see if
script changed
     */
    periodKeyCode = Ascii2KeyCode ('.');
    if (gConfiguration.hasAUX)        /* If we have A/UX (determined from gConfiguration
*/
        foundEvent = CheckAUXEventQueue (periodKeyCode, cmdKey);
    else {
        eventQHdr = GetEvQHdr()    ;                            /* Grab the event queue */
        eventQPtr = (EvQElPtr) eventQHdr->qHead;            /* Grab the first element */

        foundEvent = false;                                    /* Assume the event is not there */
        while (eventQPtr && !foundEvent) {
            foundEvent = (((eventQPtr->evtQMessage & keyCodeMask) >> 8) == periodKeyCode
&&
                (eventQPtr->evtQModifiers & cmdKey));        /* Is this the event we want? */
            if (!foundEvent)
                eventQPtr = (EvQElPtr) eventQPtr->qLink;    /* If not, grab the next element */
        }
    }

    return (foundEvent);        /* Tell them what we found */
} /* UserDidAbort */

---------------------------

From: [e-mail] (Kevin Hill)
Subject: FileFilter Procedure.  Think C 5.0 StandardGetDialog.
Organization: Crash TimeSharing, El Cajon, CA
Date: Tue, 21 Apr 1992 06:20:37 GMT

  I currently am defining a procedure that is:

Boolean FileFilterProc(CPBInfo pb,Ptr p)
{
}

 when it gets called, right now it always returns FALSE so that no filtering
occurs.  However, when it is first called, the mac Bombs at address 0xAxxxxxxx
something.  Also, I noticed when I was looking in the StandardFile.h that
several of the GetFile routines are being set to certain numbers. Can anyone
give me any hints as to why it crashes, and what the Header is setting when it
declares the functions.

  Thanks.


+++++++++++++++++++++++++++

Organization: Penn State University
Date: Tuesday, 21 Apr 1992 08:52:18 EDT
From: Christopher Tate <[e-mail]>

In article <[e-mail]>, [e-mail] (Kevin
Hill) says:
>
>  I currently am defining a procedure that is:
>
>Boolean FileFilterProc(CPBInfo pb,Ptr p)
>{
>}

File filter procs have to be declared to use Pascal calling conventions
instead of the usual C conventions.  Change the declaration to

pascal Boolean FileFilterProc(CPBInfo pb, Ptr p)
{
   /* do whatever */
}

- -------
Christopher Tate        |  "Isn't it funny how the people who cling like
                        |   barnacles to the traditional myths are always
[e-mail]    |   complaining that the rest of us are closed-
Bitnet:  CXT105@PSUVM   |   minded?"                   -- Dr. Dave

+++++++++++++++++++++++++++

From: [e-mail] (Tim Dierks, ToyMeister, Cray abuser)
Date: 23 Apr 92 21:21:15 GMT
Organization: MacDTS, Apple Computer

In article <[e-mail]>, [e-mail] (Kevin Hill) writes:
>
>
>   I currently am defining a procedure that is:
>
> Boolean FileFilterProc(CPBInfo pb,Ptr p)
> {
> }
>
>  when it gets called, right now it always returns FALSE so that no filtering
> occurs.  However, when it is first called, the mac Bombs at address 0xAxxxxxxx
> something.  Also, I noticed when I was looking in the StandardFile.h that
> several of the GetFile routines are being set to certain numbers. Can anyone
> give me any hints as to why it crashes, and what the Header is setting when it
> declares the functions.

Change your declaration to be of type "pascal"; then it will use the
Pascal calling conventions and stop crashing your Mac:

pascal Boolean FileFilterProc(CPBInfo pb,Ptr p)
{
}

In your question about the headers, I assume you mean declarations like
the following:

pascal void SFGetFile(Point where,
                      ConstStr255Param prompt,
                      FileFilterProcPtr fileFilter,
                      short numTypes,
                      SFTypeList typeList,
                      DlgHookProcPtr dlgHook,
                      SFReply *reply)
    = {0x3F3C,0x0002,0xA9EA};

In this case, the hex numbers at the end are an inline declaration; the
compiler will insert this assembly code when calling the routine rather
than attempting to JSR to a linked routine (which is what it does when
you call one of your own functions).  In this case, the assembly code
is:

    MOVE.W      #$0002,-(A7)
    _Pack3

Which pushes the selector for SFGetFile (2) onto the stack, then calls
the trap which all the Standard File routines share (Pack 3).

Hope this helps.
Tim Dierks
MacDTS, but I speak for myself

---------------------------

From: [e-mail] (John William Lawrie)
Subject: smooth scrolling
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Thu, 23 Apr 1992 10:31:01 GMT


Does anybody know how to do a smooth scroll?

  My problem is this.  I am trying to scroll a region filled with many
different colors.  What happens is that part of the region is out of synch with
the rest.  The bottom half is out of alignment a few pixels.

  What I think is happening is that the scroll is happening while the electron
beam is in the middle of the region.  This would cause the top half to be
updated only when the beam starts the next pass.

  My question is this.  Is there any way to synchronize my scroll with the
beam so that I only scroll when the beam is not drawing?

  If not, is there another way to acheive a smooth scroll effect?

Thanx in advance
John Lawrie


+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Thu, 23 Apr 1992 15:07:20 GMT

[e-mail] (John William Lawrie) writes:
>
>  My problem is this.  I am trying to scroll a region filled with many
>different colors.  What happens is that part of the region is out of synch with
>the rest.  The bottom half is out of alignment a few pixels.
>
>  What I think is happening is that the scroll is happening while the electron
>beam is in the middle of the region.  This would cause the top half to be
>updated only when the beam starts the next pass.
>
>  My question is this.  Is there any way to synchronize my scroll with the
>beam so that I only scroll when the beam is not drawing?

Yes.  But it takes a little effort.

You can tell when the electron beam has begun its trip back to the top
of the screen, because TickCount() will return you a different value.
If you sit in a tight loop:

long startTickCount = TickCount();
while (TickCount() != startTickCount) /* do nothing */ ;

...when you get out of the loop, the beam will probably be somewhere
just before starting to paint the top of the screen.  (Its exact
position depends on how long all the vertical-blanking tasks took,
including the one that incremented Ticks.  It may even have already
started its way down the visible screen, but probably not.)

Your choices here are two.  If you can update your area in one tick,
then begin immediately.  You'll constantly be rushing ahead of the beam.
If the beam gets ahead of you, your lower area will indeed "fall behind"
just as it is now.

If you can update your area in two ticks, wait for a while to let the
beam get a little ahead of you.  Then begin painting.  If you're writing
the whole screen, you have as much time as it takes for the beam to
paint two screens--you start out behind, but it's "running around to
come up behind you again," as Pink Floyd would say.  How _long_ to wait
is not an easy problem, especially given the wide disparity of speeds
that you may be running on.  You can use Gestalt to get your processor
type and/or machine type;  you can do timing loops on TickCount() to see
how many cycles you're doing (though timing the low-memory global Ticks
would be more accurate, you'd lose A/UX and future compatability).
The faster you estimate the machine to be, the more cycles you should
wait, and nothing but experimenting will help you here.

...and if you can't update your area in two ticks, then you're going to
have tearing no matter what you do, so just kick back, have a cold one,
and start trying to convince people that it's a feature.  :-)
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 My coat contained a furnace where there used to be a guy...

+++++++++++++++++++++++++++

From: [e-mail] (Russell S. Finn)
Organization: MIT Laboratory for Computer Science
Date: Thu, 23 Apr 1992 19:19:41 GMT

In article <[e-mail]>, [e-mail] (Jamie R. McCarthy) writes:
|> You can tell when the electron beam has begun its trip back to the top
|> of the screen, because TickCount() will return you a different value.

This is only true on a compact Mac with a built-in monitor.  On
modular Macs, there is still a 60.15 Hz interrupt for compatibility
reasons, and TickCount is still tied to it, but it has nothing to do
with the actual vertical retrace interrupt, which could occur at any
of a number of frequencies depending on the card and monitor used.

The solution is to install your own task on the interrupt queue of the
actual card in use; the technique for doing this can be discerned from
a careful reading of the appropriate chapters of Inside Macintosh,
Volume IV.  This task should probably do nothing more than increment a
global variable in the program; then you can use the technique Jamie
described.

|> If you sit in a tight loop:
|>
|> long startTickCount = TickCount();
|> while (TickCount() != startTickCount) /* do nothing */ ;
|>
|> ...when you get out of the loop, the beam will probably be somewhere
|> just before starting to paint the top of the screen.  (Its exact
|> position depends on how long all the vertical-blanking tasks took,
|> including the one that incremented Ticks.  It may even have already
|> started its way down the visible screen, but probably not.)

As it happens, incrementing TickCount is one of the first things that
the standard VBL interrupt handler does, so you can be fairly
confident that the beam hasn't started down the screen yet.

- -- Russell S. Finn
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Sting)
Date: 24 Apr 92 13:01:21 GMT
Organization: Dartmouth College, Hanover, NH

In <[e-mail]> [e-mail] (John William Lawrie) writes:


>Does anybody know how to do a smooth scroll?

[stuff deleted]

>  My question is this.  Is there any way to synchronize my scroll with the
>beam so that I only scroll when the beam is not drawing?

>  If not, is there another way to acheive a smooth scroll effect?

>Thanx in advance
>John Lawrie

There is a Vertical Blanking manager in the 128K (and higher) ROMs that main-
tains a queue of things to do in the interval between when the beam shuts off
at the bottom right corner of the screen and flicks back to the top to start
its next pass.  I don't have IM right here in front of me, but I believe you
could at the very least use this manager to help synchronize with the retrace
cycle.

- -Mike

- --
Michael J. Fromberger            | Take a look at my new toy,
Composer, Guitarist            | It'll blow your head in two, oh boy!
[e-mail]                | Truth hits everybody
  friendly email welcome!!         | Truth hits everyone...  (The Police)

---------------------------

From: [e-mail] (James Davis)
Subject: Are you a developer? Ive got a question.
Date: 24 Apr 92 03:04:51 GMT
Organization: Computing Services, UC Davis

If you're an apple developer (associate or partner) and
dont mind a few questions, could you drop me a note?  I had
a few questions about the developer mailing, but since half
that stuff is marked confidential dont want to ask in a public
forum.

Thanks for the willingness to help,
James Davis ([e-mail]) : University California : Computing Services

+++++++++++++++++++++++++++

From: [e-mail] (Brian Hall)
Date: Fri, 24 Apr 92 04:25:45 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

In article <[e-mail]> [e-mail] (James Davis) writes:
>If you're an apple developer (associate or partner) and
>dont mind a few questions, could you drop me a note?  I had
>a few questions about the developer mailing, but since half
>that stuff is marked confidential dont want to ask in a public
>forum.
>
>Thanks for the willingness to help,
>James Davis ([e-mail]) : University California : Computing Services

Call the Apple Developer Group at 408/996-1010.  They will be happy to send
you a package explaining the various developer programs, what you need to
do to qualify, and what you get in return.

- --
+-----------------------------------------------------------------------------+
| Brian Hall, Mark/Space Softworks                                            |
| [e-mail]; Applelink, America Online: MarkSpace                     |
+-----------------------------------------------------------------------------+

---------------------------

End of C.S.M.P. Digest
**********************